liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth
authorBen Hutchings <ben@decadent.org.uk>
Tue, 14 Jun 2016 19:44:14 +0000 (20:44 +0100)
committerBen Hutchings <ben@decadent.org.uk>
Sat, 28 Jan 2017 16:11:16 +0000 (16:11 +0000)
commitc917ce8a7131008fd07ee83df3cb15fe3ed9638d
tree141e58827f3518c1707def0b31ba9afe39b2e9e3
parentcb7b385a4d8c29a985b6351134930d9a14ce1c48
liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth

liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix
lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is
within the range of lock_chain::depth and in liblockdep it is much
too large.

That should have resulted in a compiler error, but didn't because:

- the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep
  so is assumed to be an (undeclared) function
- putting a function call inside a BUILD_BUG_ON() expression quietly
  turns it into some nonsense involving a variable-length array

It did produce a compiler warning, but I didn't notice because
liblockdep already produces too many warnings if -Wall is enabled
(which I'll fix shortly).

Even before that commit, which reduced lock_chain::depth from 8 bits
to 6, MAX_LOCK_DEPTH was too large.

Cc: <stable@vger.kernel.org> # for versions before 4.6, use a value of 255
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name liblockdep-reduce-max_lock_depth-to-avoid-overflowin.patch
tools/lib/lockdep/uinclude/linux/lockdep.h